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REMOTE GAMING MECHANISM 
Field of t:he Invention 

6 The present invention relates to an apparatus, methods 
and protocols for playing electronic games, over a 
communication network. The invention is applicable to, 
but not limited to, an apparatus, method and protocols 
for remote gaming directly between two wireless 

10 communication units over a wireless communication 
network. 

Background o£ tihe Invent:lon 

15 In the field of this invention, it is known that 

mechanisms for playing electronic-based games exist, 
whereby the games are played over a wireless or wireline 
communication network between two or more remote 
communication units. For example, remote gaming is known 

20 whereby a plurality of players interact via a network, 
for example a computer network such as the Internet, in 
order to participate in playing a game. Increasingly 
such games are being developed that make use of email and 
similar messaging services for users/parties to 

25 communicate over a network in order to play a game. 

Battlemail.com provides one such game that is available 
via the Internet. This game is described in 
International Patent Application WO0167275. The patent 
30 application describes a method for a first player, 

hereinafter referred to as the challenger, sending a 
message containing a challenge for a contest to a Server 
on the Internet. The message is structured to include 
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attack and defence moves. The Internet Server extracts 
the challenge information, processes it and then 
generates a further (second) challenge message. The 
Internet Server sends this second challenge message to a 
5 second player, hereinafter referred to as the opponent . 

On receipt of the challenge message from the Server, the 
opponent is able to accept the challenge, and send a 
response message back to the server containing its own 

10 attack and defence moves. On receipt of the response 

message, the Internet Server extracts the response data. 
With the challenge data extracted from the challenge 
message from the challenger, together with the response 
data extracted from the response message from the 

15 opponent, the Internet Server is able to process both 
sets of data to determine the outcome of the contest. 
The Internet Server subsequently generates result 
messages and sends one to each of the challenger and 
opponent, informing them of the outcome of the contest. 

20 

The inventors of the present invention have recognised a 
number of problems associated with such a remote gaming 
method. First, the communication of challenge and 
response messages over a communication network requires 
26 the use of a dedicated server. Communication to and from 
the dedicated Server utilises a number of communication 
paths, thereby utilising valuable communication resource- 

Another disadvantage of the method of gaming provided by 
30 Battlemail.com is that of the results of contests being 
determined by the server. If a large niHtiber of contests 
take place at any one time, the server is required to 
handle the various messages and determine the results of 
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the contests on its own. Particularly in a bandwidth 
constrained communication network, such a processing 
requirement placed on the Server could seriously slow 
down the gaming experience for users. The effect of this 
5 may be to dissuade players from playing the game in 
future . 

Furthermore, if the server is inoperable for any reason, 
the players are prevented from playing the game. Again, 
10 the effect of any downtime of the Internet site may be to 
dissuade players from playing the game in future. 

Computer networks are not the only networks over which 
players can interact to play games. Communication 

15 networks, and in particular wireless communication 
networks .such as GSM (Global System for Mobile 
communication) networks, GPRS (General Packet Radio 
System) networks and 3G (3'''* Generation) networks, are 
increasingly being explored as means for connecting 

20 players of games. Such networks have a severe bandwidth 
limitation. Additionally, a player may be charged for 
each transmission (and perhaps reception) from the 
wireless communication unit. Therefore, the inventors of 
the present invention have recognised that a key issue 

25 for playing games over such wireless networks is to keep 
the ht^ii?sfeer of messages between players to a minimum. In 
this manner, the amount of bandwidth required to play the 
game is reduced and the cost to the user is minimised. 
Furthermore, the inventors have appreciated that certain 

30 remote gaming users may prefer to conmiunicate directly 
between one another, thereby avoiding the potential 
Mown-time' inconvenience of a gaming web-site* 
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A need therefore exists for an improved remote gaming 
mechanism, together with associated communication units, 
protocols and message formats supporting the gaming 
mechanism, wherein the abovementioned disadvantages may 
5 be alleviated. 

Shat^B®nb of lnven1:ion 

In accordance with a first aspect of the present 
10 invention, there is provided a communication unit for 
playing a game with a second remote communication unit, 
as claimed in Claim 1* 

In accordance with a second aspect of the present 
15 invention, there is provided a gaming server configured 
to operate as the second communication unit, as claimed 
in Claim 11. 

In accordance with a third aspect of the present 
20 invention, there is provided a wireless, computer-based 
or processor-based game, as claimed in Claim 12^ 

In accordance with a fourth aspect of the present 
invention, there is provided a communication protocol 
26 supporting a remote gaming mechanism, as claimed in Claim 
13. 

In accordance with a fifth aspect of the present 
invention, there is provided a communication system, as 
30 claimed in Claim 16. 

In accordance with a sixth aspect of the present 
invention, there is provided a storage medium storing 
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processor-implementable instructions for controlling one 
or more processors, as claimed in Claim 17* 

Further aspects and advantageous features of the present 
5 invention are as described in the appended Claims. 

In summary, the present invention provides an improved 
remote gaming mechanism. In particular, one or more 
communication units participating in the game, either as 
10 a challenger or opponent has been adapted to determine 

the outcome of a contests If the communication unit is a 
challenging communication unit, the communication unit 
may store, or receive back from the opponent, the 
challenge data, 

16 

The communication unit may also receive response data 
from an opponent. The communication unit is configured 
to determine the outcome of the contest from the two sets 
of data. If the communication unit is the opponent, the 

20 communication unit stores the received challenge data 

and, if the challenger is a similar remote communication 
unit, preferably transmits the response data to the 
challenger. Nevertheless, the communication unit is 
configured to determine the outcome of the contest using 

25 the received challenge data and any contest or response 
data generated by a user of the communication unit or 
stored within the coiranunication unit. 

Brxef Descript:ion of the Drawings 

30 

Exemplary embodiments of the present invention will now 
be described, by way of example only, with reference to 
the accompanying drawings, in which: 
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FIG. 1 illustrates a block diagram of a wireless 
communication unit operating in a wireless communication 
system, adapted to support the inventive concepts of the 
5 preferred embodiments of the present invention; 

FIG, 2 illustrates a message flow diagram between two 
communication units operating in accordance with the 
preferred embodiment of the present invention; 

10 

FIG. 3 illustrates a flowchart of a communication unit 
sending a challenge message in accordance with the 
preferred embodiment of the present invention; 

15 FIG. 4 illustrates a flowchart of a communication unit 
receiving a challenge message in accordance with the 
preferred embodiment of the present invention; 

FIG. 5 illustrates a flowchart of a communication unit 
20 responding to a received challenge message in accordance 
with the preferred embodiment of the present invention; 

FIG. 6 illustrates a flowchart for determining an outcome 
of a remote game facilitated in accordance with the 
25 preferred embodiment of the present invention; 

FIG. 7 illustrates a block diagram of a wireless 
communication unit operating in a wireless communication 
system, adapted to support the Inventive concepts of an 
30 alternative embodiment of the present invention; 

FIG. 8 illustrates a message flow diagram between two 
communication units and an intermediate gaming server in 
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accordance with an alternative embodiment of the present 
invention; 

FIG. 9 illustrates the known short message service (SMS) 
5 message structure of the GSM communication system,, 

utilised in accordance with the preferred embodiment of 
the present invention; 

FIG. 10 illustrates the user data header of an SMS 
10 message utilised in accordance with the preferred 
embodiment of the present invention; 

FIG- 11 illustrates the information element of an SMS 
message adapted to support the preferred embodiment of 
15 the present invention; 

FIG. 12 illustrates the message data of an SMS message 
adapted to support the preferred embodiment of the 
present invention; 

20 

FIG, 13 illustrates a format for the challenger and 
opponent data applied to an SMS message to support the 
preferred embodiment of the present invention; 

25 FIG, 14 illustrates a character attribute format for the 
challenger employed in accordance with the preferred 
embodiment of the present invention; and 

FIG. 15 illustrates an attack/defence move data 
30 arrangement employed in accordance with the preferred 
embodiment of the present invention. 

Description o£ Preferred Eiabodinients 
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The preferred embodiment of the present invention is 
described with reference to a portable cellular phone 
capable of transmitting messages, for example, SMS 

5 messages over a current or future generation of wireless 
cellular technology. However, it is within the 
contemplation of the present invention that the inventive 
concepts described herein are equally applicable to any 
other wireless or wireline communication unit, such as a 

10 personal data assistant (PDA) , a portable or mobile 
radio, a laptop computer or a wirelessly networked 
personal computer (PC) that is able to support remote 
gaming . 

15 FIG. 1 illustrates a block diagram 100 of a pair of 
coinmunication units 110, 120, operably coupled via a 
communication network 130, and adapted to support the 
inventive concepts of the present invention. In the 
illustrated embodiment, the pair of coinmunication units - 

20 first terminal 110 and second terminal 120 - are wireless 
communication devices such as cellular mobile telephones, 
and the network is a wireless communication network such 
as a GSM network. 

25 Each of the first and second terminals 110, 120 comprise 
an antenna 135 and transceiver circuitry (not shown) 
operably coupled to a processor 160. The processor 
includes communication software 140, to allow the 
terminals 110, 120 to communicate with the network 130* 

30 The processor 160 of each terminal 110, 120 further 

comprises gaming software 140 to enable the processor to 
provide the functionality necessary for the terminal to 
participate in a remote game* In addition, the processor 
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160 has been adapted to determine an outcome of a game; 
based on a single received message that includes 
challenge (or response) data, together with the selected 
response (or challenge) data of that terminal - 

5 

It is within the contemplation of the invention that the 
processor 160 is operably coupled to a memory element 170 
of the terminal 110 , 120 such that the processor 160 or 
associated memory element 170 may be re-programmed with 
10 data or an algorithm (such as that described with respect 
to FIG. 3, FIG. 4^ FIG. 5 or FIG. 6) supporting the 
inventive concepts of the present invention^ as described 
below. 

15 More generally, according to the preferred embodiment of 
the present invention, such re-programming to effect an 
improved remote gaming mechanism may be implemented in a 
respective terminal in any suitable manner- For example, 
a new memory chip or processor may be added to a 

20 conventional cellular subscriber unit. 

Alternatively, existing parts of a terminal 110, 120 may 
be adapted, for example by reprogramming one or more 
processors therein. The adaption may include (re-) 

25 programming of the processor 160 to support the gaming 
protocol or message structure as described with respect 
to any of FIG. 10 to FIG. 15. As such, the required 
adaptation may be implemented in the form of processor- 
implementable instructions stored on a storage medium, 

30 such as a floppy disk, hard disk, programmable ROM 

(PROM) , RAM or any combination of these or other storage 
media* 
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10 



15 



20 



25 



30 



Users of the terminals 110, 120 are able to interact/ 
coiomunicate 125 with one another over the coinmunication 
network supported by, say, base station 130, in order to 
play a game. In an alternative embodiment of the present 
invention, it is envisaged that the terminals 110, 120 
are able to interact/communicate 128 directly with one 
another, for example over a bluetooth communication link, 
a wireless local loop (WLL) , a direct-mode or two-way 
radio link, etc. 

According to the present invention, this is achieved by 
the user of the first terminal 110, hereinafter referred 
to as the challenger, initiating a game. The challenger 
initiates a game by selecting challenge parameters from a 
list of options using the gaming software 150. Such an 
initiation can be effected via the man machine interface 
(MMI) 18 0, which preferably includes an output device 
such as a display and an input device such as a keypad or 
keyboard (not shown) . The gaming software 150 passes 
challenge parameters, together with optional opponent 
details, to the communication software 140 of the 
processor 160. The challenge parameters are used by the 
processor 160 to create a challenge message. The 
challenge message is then transmitted over the 
communication network 130 to the second terminal 120. 

The second terminal 120 receives the challenge message, 
and the challenge (parameters) data and challenger 
details are extracted from the message by the 
communication software 140. The challenge parameters are 
then passed to the gaming software 150. The user of the 
second terminal 120, hereinafter referred to as the 
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opponent r is then able to accept or reject the challenge^ 
for example via the MMI 180. 

On accepting the challenge, the opponent generates a 
5 response. The gaming software 150 passes response data 
together with challenger details to the communication 
software 140. The processor 160, in co-operation with 
the communication software 140 creates a response message 
and transmits the response message over the network 130 
10 to the first terminal 110. 

Once the communication software 140 of the second 
terminal 120 has transmitted the response message, or 
once the gaming software 150 has passed the response data 

15 and challenge data to the communication software 14 0, the 
gaming software 150 of the second terminal 120 is able to 
determine the outcome of the contest by itself. In this 
regard, the gaming software processes the challenge data, 
extracted from the challenge message, together with the 

20 response data and implements (acts out) the contest in 
order to determine the result. 

The result of the contest is provided to the user, for 
example displayed on a screen (say, the MMI display) of 

25 the terminal 120. This may be achieved once the gaming 
software 150 has completed processing the data and 
determined the final result. Alternatively, and/or 
additionally, as the data is being processed, the various 
stages of the contest can be displayed to the user, for 

30 example each attack move made by the players. This 
feature is particularly advantageous over comparable 
remote fighting games such as the Battlemail game, which 
only shows the results - the contest having being 



wo 03/092839 



- 12 - 



PCT/GB03/01785 



resolved at a remote server^ with only the result of the 
contest being transmitted to the participants. 

It is envisaged that the preferred option of displaying 
5 various stages would be the default option - 

Alternatively, it may be provided to the user via the MMI 
180, and selectable via the processor 160. Furthermore, 
it is envisaged that the user is provided with the 
ability to interrupt a round-by-round account, in order 
10 to simply skip to the end of the contest where the final 
(determined) result may be displayed. 

The communication network 130 communicates the response 
message, transmitted by the communication software 140 of 

16 the second terminal 120, to the first terminal 110. The 
communication software 140 of the first terminal 110 
receives the response message, and extracts the challenge 
data and the response data therefrom. The challenge data 
and response data are then passed to the gaming software 

20 150 where, in the same manner as above for the second 

terminal 120, the result of the contest may be determined 
and displayed to the user. 

Referring now to FIG. 2, there is illustrated the 
25 preferred message flow, between the challenger terminal 
110 and the opponent terminal 120, required in order for 
a single game to take place. However, the inventors of 
the present invention envisage that in alternative 
embodiments the data to participate in multiple games 
30 could be transmitted in a single (challenge or response) 
message. In this regard, the data protocols and message 
formats need to be configured to handle the increased 
data content. As can be seen^ in the preferred 
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embodiment of the present invention, only two messages 
are required. Namely, a first, challenge message 210 
, from the challenger to the opponent and a second, 
response message 220 from the opponent to the challenger. 

5 

The challenge message 210 comprises the challenge data, 
which at least comprises the challenger moves, such as 
attack moves and defence moves. In this manner, all 
challenge data required by the opponent in order for a 
10 contest to take place is provided in the initial 

challenge message 210. This allows the gaming software 
150 of the second terminal 120 to determine the result of 
the contest, on its own account, without requiring 
further data or information from the first terminal 110. 

15 

The response message 220 preferably comprises both the 
challenge data and the response data. As for the 
challenge message 210, the challenge data comprises at 
least the challenger moves, such as attack moves and 

20 defence moves. In the same manner, the response data 
comprises at least the opponent moves, such as attack 
moves and defence moves. In this manner, all challenge 
data and all response data required to enable a contest 
to take place are provided in the response message 220. 

25 By providing all of the required opponent data in the 
response message 220, the gaming software 150 of the 
first terminal 110 is able to determine the result of the 
contest • 

30 Advantageously, by also providing all of the required 
challenge data in the response message 220, it is not 
necessary for the initial challenge data to be stored in 
an area of memory in the first terminal 110^, and 



wo 03/092839 



- 14 - 



PCT/GB03/01785 



subsequently retrieved on receipt of the corresponding 
response message 220. This reduces the memory 
requirement of (at least) the first terminal 110. 

5 Furthermore, since there is a possibility that the 

opponent may reject, i.e. not accept, a challenge, the 
first terminal 110 will receive no response message. 
Therefore, if challenge data is stored in an area of 
memory of the first terminal 110, without a corresponding 

10 response message 220 being received, the challenge data 
stored in memory is wasted. 

FIG. 3 illustrates a flowchart 300 of the process for 
sending a challenge to an opponent. The process starts 
15 by the user initiating the gaming software, as in step 
305. For example, the user accesses an option in a menu 
of a man machine interface (MMI) 180 of the first 
terminal 110. 

20 On initiating the game, user game profile information 
that has been previously created, for example, during 
previous games etc., is copied from an area of non- 
volatile memory (NVM) , as in step 310. The user game 
profile information may be stored in an area of system 

25 memory, such as random access memory (RAM) ♦ 

In the preferred embodiment of the present invention, the 
user game profile information may include, by way of 
example, any one or combination of the following 
30 information: 

(i) A user's gaming identity, or ''alias". 

(ii) A character reference, relating to the user's 
preferred character^ 
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(iii) Character attributes^ such as strength, 
attack skill, defence skill, stamina/health etc, each of 
which may be improved through playing the game* 

(iv) A user^s credit or points, which may be 
6 earned through playing the game. 

(v) References to the character's equipment, 
including weapons, armour etc, . which may be bought, 
improved or sold in exchange for credit. 

10 In the Battlemail game, a player receives extra points 
that can be distributed among the attributes to improve 
them when the player has achieved a sufficiently high 
score. In contrast to the Battlemail game the preferred 
embodiment of the present invention awards credits in 

15 contests, which can then be used to buy new equipment or 
pay for training to improve health, strength, attack 
skill or defence skill. The total number of credits 
earned (or points), whether spent or not, may also be 
used at the end of the contest as a way of gauging a 

20 user's gaming experience. Namely, the player who has 

earned the most gold will be deemed the more experienced. 
The difference in experience between two players is then 
used to vary the amount of gold that can be earned in a 
contest, going in favour of the weaker player. 

25 

Once the user profile has been retrieved from memory, the 
user is able to initiate a challenge, as in step 315,. by 
selecting a "challenge'' option from a list of game 
options. The list of options may include one or more of 
30 the following: 

(i) ^'Challenge" ^ create and send a challenge to 
another player; 
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(ii) ^'Messages" - view challenges and/or responses 
received; 

(iii) ^^Profile" - view the user profile; 

(iv) ^^Attributes'' - change/improve character 

5 attributes, for example following purchasing equipment, 
training etc; 

(v) ^'Replay previous contests'' - those contests 
that have been saved; 

(vi) ^^Quit", 

10 

Once the user has initiated a challenge, by selecting the 
challenge option, character information is copied into a 
message buffer, as in step 320. The character 
information copied into the message buffer may include 
15 the user's alias, the character reference, equipment 
references, character attributes, user's credit and/or 
user's points. 

Next, the user is preferably provided with the option of 
20 entering/selecting opponent details, as in step 325 • For 
example, where the game is to be played between two 
cellular mobile telephones the user may enter the 
telephone number for the cellular mobile telephone of the 
opponent. Alternatively, the user may retrieve the 
25 telephone number from a list of numbers stored in an area 
of memory of the telephone, such as a contacts list, 
address book, etc. 

Once the user has entered/selected the opponent details, 
30 these details are stored in system memory, as in step 
330, 
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Subsequently the user enters the desired moves, for 
example starting with the attack moves, as in step 335, 
which are preferably stored in the message buffer, as in 
step 340. The user may then enter the defence moves, as 
5 in step 345, which are also preferably stored in the 
message buffer, as in step 350. 

Having entered/selected all required information, the 
user is then able to transmit a challenge, as in step 360 

10 to a prospective opponent. This results in the challenge 
data being stored in a message buffer linked to the 
communication software 140, along with the opponent's 
details and any other required information, as in step 
370. The communication software 140 receives the 

15 information and challenge data, and creates the challenge 
message. The communication unit then transmits the 
challenge message to the opponent, via the communication 
network 130, as in step 380. 

20 AS previously mentioned, there is no need for the 
challenge data sent in the challenge message to be 
retained, since if the opponent accepts the challenge, it 
is envisaged that the challenge data will be provided in 
the response message. Therefore, the challenge data can 

25 subsequently be discarded, once the challenge message has 
been sent . 

However, if memory space in the communication unit is not 
a scarce resource, it is envisaged that the challenge 
30 data may be retained in a memory element of the first 

terminal. In this manner, the response from the opponent 
may be simplified by only including the response data and 
not replicating the challenge data. Furthermore, in this 
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scenario, it is envisaged that the challenge data may be 
deleted from the memory after a time period, if no 
response has been received. 

Referring now to FIG. 4 and FIG. 5, flowcharts 400, 500 
illustrate the processes involved when a challenge 
message, or a response message, is received. The 
processes start when a game message, whether a challenge 
message or a response message, is received in step 410 in 
the flowchart of FIG. 4. The message is received by the 
communication software, which extracts the challenge/ 
response data and the challenger/ opponent details. The 
details are preferably stored in NVM, as in step 420, 
The user is then informed of the receipt of the message, 
15 as in step 430. 

If the user has not already initiated the gaming 
software, this is performed, as shown in step 440. The 
user profile is retrieved from NVM and stored in system 
20 memory, as in step 450. 

The user selects, for example from the list of options 
described above, to view any received game messages, as 
in step 4 60. Sender details and message type for each 
game message stored in NVM may be retrieved and displayed 
to the user, as in step 470. The user then selects one 
of the game messages, as in step 480. The type of 
message selected in step 490, i.e. challenge or response, 
determines the next course of action. 



25 



30 



It can be seen that if the message selected by the user 
in step 480 is a response message, the challenge data and 
response data provided by the response message are 
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10 



retrieved from NVM and stored in memory^ as in step 495. 
The gaming software then uses the challenge data and 
response data to determine the outcome of the contest. 

FIG* 5 illustrates the steps taken when the message 
selected by the user is a challenge message. The user is 
provided with the option of accepting or declining the 
challenge, as in step 505. If the user declines the 
challenge, the challenge data and associated information 
are deleted from both the system memory and NVM. Since 
the terminal of the challenger does not retain the 
challenge data in the preferred embodiment, there is no 
requirement for a message to be sent to the challenger 
informing the challenger, or his/her terminal, that the 
15 challenge has been declined. 

If the user accepts the challenge, the challenge data is 
retrieved from NVM, and stored in a message buffer, and 
the challenger's details are stored in the system memory, 
as in step 515. Next, the user's character information 
is copied from system memory into the message buffer, as 
in step 520 • 

In the same manner as for steps 335 to 350, when 
generating a challenge message, the subsequent steps 525 
to 545 when generating a response message include the 
user (opponent) entering attack and defence moves. These 
moves are stored in the message buffer, and the opponent 
transmits the response to the challenger. 

The data stored in the message buffer, comprising both 
the challenge data and the response data, together with 
the challenger's details., are passed to the communication 



20 



25 



30 
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software, as in step 550. The communication software 
uses the data to create the response message. The 
message is then sent to the challenger, via the 
communication network 130 ^ as shown in step 555. 

5 

Once the response message has been sent, or once the data 
has been passed to the communication software to send, 
the gaming software uses the challenge data and response 
data, still located in the message buffer^ to determine 
10 the outcome of the contest. 

FIG. 6 illustrates an example of how the result of a 
contest is determined by the communication unit. The 
initial requirement is for the game variables to be set, 
16 as in step 605* In the illustrated embodiment these are: 

(i) ^"Round'^ this provides a counter for the 
rounds in the contest; 

(ii) "^ChlHP", which represents the health points 
for the challenger; and 

2Q (iii) ''OppHP", which represents the health points 

for the challenger. 

Additional/ alternative variables may be, for example, 
variables representing: 
25 (iv) The strength of the challenger and opponent. 

(V) The attack and defence skills of the 
challenger and opponent. 

(vi) The damage characteristics of the weapons of 
the challenger and opponent* 
30 (vii) The defensive characteristics of the armour 

and/or shield of the challenger and opponent - 

(viii) The stamina or health characteristics of 
the challenger and opponents 
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The following descriptions clarify a preferred example of 
some of the aforementioned variables. 

5 Character strength: A player starts with a default 
strength value. Strength can be improved, i.e. 
increased, by buying appropriate training. In the 
preferred embodiment of the present invention, the effect 
of strength relates to the user's armour. If the armour 
10 is too heavy for the user, damage inflicted by the user 
when attacking is reduced (due to the armour inhibiting 
the user) . 

Attack and defence skills: A player starts with a default 
15 attack skill value and a default defence skill value* 
These can both be improved by buying appropriate 
training. These skills affect the amount of 
health/stamina a player loses when attacked (i»e- the 
greater the attack skill the more health is lost, the 
20 greater the defence skill the less health is lost). 

Damage characteristics of weapon: The weapon damage value 

depends upon the weapon the user has it his/her disposal. 

The user can buy different weapons. The weapon damage 
25 value is used: 

a) When an opponent defends (noting that if the 

opponent's shield value is less than the weapon damage 

value the difference is used to determine the health lost 

by the opponent ) ; and 
30 b) When the opponent does not defend again to 

determine the health lost by the opponents 
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Defensive characteristics: This depends on the armour of 
the player. In the preferred embodiment, the armour 
consists of a helmet, a breastplate and boots, each 
having individual defensive points for high, mid and low 
6 armour. If the player is defending, armour is not used 
if the shield is defined as being stronger than the 
opponent's weapon. However, if the shield is weaker than 
the weapon, or the player fails to defend, the stronger 
the armour the less health is lost. 

10 

Health/stamina: The player starts with a default health 
value. Health/stamina can be improved by buying 
appropriate training. The more health points the player 
has, the longer the player can last, since more health 
15 points need to be lost before the player is 
incapacitated, etc. 

The variable ^^Round" is initially set to a ^1', 
indicating the first round. ^''ChlHP" and ^^OppHP" are 
20 initially set to ^3' each, providing each character with 
an initial health value. 

Next, the first round begins with the challenger's first 
attack (being the first round) move (ChlAtt (Round) ) being 
26 compared to the opponent's first defence move 

(OppDef (Round) ) , as in step 610. If the challenger's 
attack move is equal to the opponent's defence move, the 
opponent effectively defends the attack. 

30 Where the opponent fails to defend an attack from the 
challenger, a point is deducted from the opponent's 
health ^^OppHP"r as in step 615. If the opponent's health 
is equal to ^0', as in step 620, the opponent has been 
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knocked out. At this juncture the contest, or bout, is 
over, as shown in step 625. Otherwise, the process moves 
on to the next part of the round where the opponent 
attacks, as in step 630, After the opponent has defended 
5 or attempted to defend the challenger' s attack, the 

process moves on to the next part of the round where the 
opponent attacks the challenger, as in step 625, 

In alternative embodiments, other factors may affect the 
10 amount by which the health of the opponent is reduced • 
It is envisaged that such factors may include one or a 
combination of: 

(i) The strength of the challenger and opponent, 

(ii) The attack and defence skills of the 
16 challenger and opponent • 

(iii) The damage characteristics of the weapons of 
the challenger and opponent. 

(iv) The defensive characteristics of the armour 
and/or shield of the challenger and opponent. 

20 (v) The stamina or health characteristics of the 

challenger and opponent. 

In step 630, if the opponent's first attack move 
(OppAtt (Round) ) is equal to the challenger's first 
25 defence move (ChlDef (Round) ) the challenger effectively 
defends the attack. 

When the challenger defends the attack, the process moves 
to the end of the round, as in step 650. However, where 
30 the challenger fails to defend the attack^ a point is 

deducted from the challenger' s health ^^ChlHP'% as in step 
635. If the opponenf^s health is then equal to ^0', in 
step 640|r the opponent has been knocked out^ and the 
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contest, or bout, is over, as in step 645. Otherwise, 
the process moves on to the next round with the 
challenger attacking in step 610, 

5 Again, it is envisaged that other factors may affect the 
amount by which the health of the opponent is reduced, 
for example the type of weapons used, the training 
purchased, etc. 

10 At the end of the round, the '"Round" variable is 

incremented by '1', as in step 650. If the ''Round'' 
variable has a value greater than then five rounds 

have taken place, and the contest is over. However, 
where the ''Round" value does not have a value greater 

15 than ^5', i-e. less than five rounds have been played, 
the process returns to the beginning of the next round, 
as in step 610. 

It will be appreciated that the number of rounds to be 
20 played is illustrated as being "5' * This may be set to 
any appropriate value, and may be determined by the 
challenger and/or the opponent. 

The outcome of the contest preferably also determines how 
26 the user's character attributes, etc. are affected. For 
example, the user may earn points and/or credit for 
winning a contest or for the amount of health deducted 
from the other player, etc* 

30 At the end of the contest, the result is provided to the 
user, for example displayed on a screen of the terminal, 
along with any changes to the player's attributes etc. 
Preferably, the contest is also displayed in a graphical 
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form^ for example the characters of the players being 
shown attacking and defending. This may be displayed 
once the overall outcome of the contest has been 
determined. Alternatively, as each round or 
5 attack/defence move is evaluated, that round or 

attack/defence move is displayed graphically to the user. 
The user is preferably able to select the mode of 
operation via the MMI. 

10 In a preferred embodiment of the present invention, a 

user is also able to save the contest in NVM, in order to 
enable the user to replay the contest at a later stage. 
This may be in the form of a graphical representation of 
the contest^ or alternatively in the form of the 

16 challenge and response data* 

In order to reduce the amount of data that is required to 
be included in the challenge and response messages, 
preferably attributes such as the user's character, the 

20 weapons r armour etc, are each determined using references 
to a table of attributes. For example, for the user's 
character, the user is able to select a character from a 
selection. Each terminal has an identical, or at least 
similar, selection of characters, the graphical 

25 representations for which are stored in NVM, Each 
character has a character reference that is used to 
obtain the graphical representation of the character from 
a lookup table area in memory. 

30 Thus, it is not necessary to include in the challenge 
and/or response message data providing the graphical 
representation of the character, only the character 
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reference^ which can be used to locate the graphical 
representation (s) from the NVM of the terminal. 

This is particularly advantageous when playing the game 
5 via, for example, GSM networks utilising SMS messages for 
transmitting and receiving the game messages, since only 
a single SMS message is required for transmitting the 
challenge data and the response data, and the amount of 
data should be kept to a minimum. 

10 

Referring now to FIG. 7 and FIG. 8, a yet further 
embodiment of the present invention is described- In 
this further embodiment, it is envisaged that the gaming 
messages may be routed via, or initiated from, a Central 
16 Gaming Server 710. It is envisaged that the Central 
Gaming Server 710 may be operably coupled to any 
intermediate communication unit, such as a GSM base 
station 130, or operating as a stand-alone unit. 

20 In the context of the Central Gaming Server 710 routing 

challenges/responses, it is possible for a player to send 
challenges to other players without having to know 
necessarily the details of the other players. 
Advantageously, a challenger may initiate a contest with 

25 unknown users who, for example, have expressed/registered 
an interest with the Central Gaming Server 710 to 
participate in such contests. 

In the context of the Central Gaming Server 710 
30 initiating a contest, it is envisaged that the Server 710 
may transmit challenge messages to communication units 
periodically or intermittently. Again, in this regard, 
it is envisaged that users may have registered an 
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interest in a particular game^ supported by the Central 
Gaming Server 710. It is also envisaged that an operator 
may impose a charge for such centrally initiated and 
transmitted challenges. 

5 

The Central Gaming Server 710 transmits a challenge to 
any remote communication units 110, 120 that are capable 
of accepting such a challenge. Any remote communication 
unit 110^ 120 that accepts the challenge, may determine 

10 the outcome of the contest based on the received 

challenge. The remote communication unit 110, 120 uses 
the challenge details, together with any input response 
from the user, say via MMI 180, or any response stored in 
memory 170. Notably, as there is no need to transmit a 

15 response to the Central Gaming Server 710, the contest 
only requires the transmission of a single challenge 
message . 

Referring now to FIG. 8, a message flow diagram between 
20 two communication units and an intermediate (central) 

Gaming Server 710 is illustrated, in accordance with an 
alternative embodiment of the present invention. The 
preferred message flow is from the challenger terminal 
110, via the Gaming Server 710, to the opponent terminal 
25 120. As can be seen, when the Gaming Server 710 performs 
a routing operation only two messages 210, 220 are 
required. Namely, a first, challenge message 210 from 
the challenger via the Gaming Server 710 to the opponent 
and a second, response message 220 from the opponent via 
30 the Gaming Server 710 back to the challenger. In this 
manner, the Gaming Server 710 may extract an identity of 
the intended opponent from the challenge message and 
forward the challenge to the opponent. 
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Notably^ in this alternative, when the Gaming Server 
initiates a challenge/ the Gaming Server 710 takes the 
place of the challenger. In this context, the Gaming 
5 Server generates and only transmits the challenger 

message 210, No response message 220 is required back 
from the opponent 120, 

Message Protocol 

10 

The preferred message protocol, for performing the remote 
gaming mechanism described above, utilises the short 
message service (SMS) used by wireless communications 
devices, such as mobile phones, that are compliant with 
16 the Global System for Mobile Communications (GSM) 
recommendations . 

However, it will be appreciated that the message protocol 
of the present invention may equally be implemented in 
20 other messaging formats. One example of alternative 

message protocols could be electronic mail messaging used 
for computer networks such as the Internet. 

SMS point-to-point messaging is defined in the 
26 recommendation GSM 03,40, with the basic structure of an 
SMS message at the Short Message Transfer layer being 
illustrated in FIG- 9- The SMS message is divided into 
octets, highlighted as rows for clarity purposes only, 
where each octet comprises eight bits numbered ^0' to 

30 ^7' . 

As can be seen, the last section of the SMS message is 
used for Transfer Protocol User Data (TP-UD) , This 
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section can be up to one hundred and forty octets in 
length. The Transfer Protocol-User Data Header 
Identifier (TP-UDHI) field in the first octet of the 
message is used to indicate when a user data header is 
5 present in the user data section. In accordance with the 
present invention, the TP-UDHI field is set to a binary 
value of ^l'', indicating the presence of a user data 
header • 

10 The user data header is located at the beginning of the 
user data section, and is illustrated in FIG. 10. As 
illustrated, the first octet of the user data header (and 
therefore of the user data section) provides the overall 
length of the user data header, which tor the illustrated 

16 embodiment is ^12' (octets), excluding itself* 

The second octet of the user data header is used for the 
'^Information Element Identification' (lEI) , which 
identifies the type of message, for example a 
20 concatenated short message, 8-bit reference number, 
special SMS message indication etc. For the present 
invention, the lEI preferably has a value of ^0x9F' , 
identifying the message as ''SME to SME specific use". 

25 The third octet in the user data header provides the 
length of the information element, which for the 
illustrated embodiment is '10'' (octets), excluding 
itself. The last ten octets of the user data header 
comprise the '^Inf ormation element", which contains the 

30 actual header information. 

Referring to FIG. 11, the contents of the ten octets of 
the information element are illustrated in more detail. 



wo 03/092839 



- 30 - 



PCT/GB03/01785 



For the present invention, the first five octets are used 
to identify the message as being of a specific set of 
messages. In the illustrated embodiment, the five octets 
(octets 3 to 7 of the user data header) contain,- in 
5 order, the ASCII values "^E", ""N'S '"D'', and ^^O", 

which identify the messages as being a part of a set of 

^^Sendo™" messages. 

The next octet contains a message identifier, which for 
10 the illustrated embodiment is a gaming message 

identifier. This identifies the message as being related 
to a game. The following octet (^9' of the user data 
header) contains a game message type identifier, which 
identifies the purpose of the game message. For the 
15 illustrated embodiment, this identifies the purpose of 
the game message as being an interactive gaming message 
(as opposed to a game download message for downloading a 
new game or a game update message for updating a game 
etc. ) . 

20 

The next octet identifies the game subset ID, for example 
to identify whether a game runs on a proprietary virtual 
machine^ a Java virtual machine or in its own 
application. 

25 

The penultimate octet is used for the unique game ID, 
which identifies the game with which the message is to be 
associated. Finally, the last octet of the information 
element is reserved for further identities. 
30 Alternatively, the last octet may be used to increase the 
size of the unique game ID to two octets* 
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Following the user data header, starting at octet ^3' of 
the user data section of the message, is the message 
data. This is illustrated in FIG. 12. Octet ^13' 
contains a value representing the message type. For the 
5 illustrated embodiment, there are at least two message 
types, namely ''Challenge" or "'Response'^ The next three 
octets, namely to *16', provide further game data, 

such as the version of the particular game, etc. Octets 
'17' to '74' are used for the Challenger data, and 
10 finally octets ^75' to '132' are used for the Opponent 
data, as shown. 

FIG. 13 illustrates the preferred format for the 
challenger and opponent data. The first four octets are 
15 used for a unique user ID. This allows challenges and 
responses to be associated with one another. 

The next twenty^eight octets ('21' to "48') contain an 
alphanumeric string providing a player ''alias". Unicode 
20 2.0 is preferably used to represent the string in binary. 
Unicode is a universal character-encoding standard for 
representation of text for computer processing, developed 
by the Unicode Consortium™. 

25 The next ten octets ('49' to "58') provide the character 
attributes, as illustrated in more detail in FIG. 14 for 
the Challenger. The first octet for the character 
attributes provides an index reference for the character 
of the challenger or opponent. This reference is used to 

30 locate the graphical representations etc* of the 

character from a table held in an area of memory of the 
mobile phone, or other device, to which the message is 
sent « 
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The next four octets (^50^ to ^53') for the character 
attributes provide integer values for health point S/ 
strength, combat /attack skill and defence levels 
5 respectively. The final five octets (^54' to '58') of 
the character attributes provide index references for 
weapon, shield, helmet, breastplate and boots 
respectively. 

10 Referring back to FIG. 13, the five octets ("59' to '63') 
following the character attributes provide the attack and 
defence moves of the challenger/opponent. These are 
illustrated in more detail in FIG. 15, wherein it can be 
seen that each octet is divided into two parts, one part 

15 providing an attack move and the second part providing a 
defence move. In this way five attack moves and five 
defence moves can be provided using five octets. 

Referring back to FIG. 13 once again, following the 
20 attack and defence moves, the next four octets ('64' to 
^67') provide an integer value representing the player 
score of the challenger/opponent. The subsequent four 
octets ('68' to '71') provide an integer value for the 
player credit of the challenger/opponent. 

25 

Finally, the last three octets ('72' to '74') are used 
for spacing, padding out the challenger /opponent data 
such that it takes up a number of octets ('17' to '132') 
divisible by four (i.e. 116). One reason for having the 
30 number of octets divisible by four is to provide a 32 
boundary (4*8 octets) to provide for 'Double Word 
alignment' as required by compilers. 
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It is within the contemplation of the invention that the 
inventive concepts hereinbefore described are not limited 
to the particular game of the preferred embodiment. 
Indeed, it is envisaged that the concepts are applicable 
5 to any game format where moves can be pre-determined, or 
a player enters a set of moves, that are not dependent 
upon knowledge of an opponent's response, such as 
^chess' . One example of a game that can be implemented 
would be a penalty shootout type football game, where the 
10 moves are shoot and save, instead of attack and defend. 

The preferred embodiment of the present invention has 
been described with reference to a wireless environment 
with a processor-based game residing in a wireless 
16 communication unit. However, it is within the 

contemplation of the invention that the inventive 
concepts are equally applicable to a wire-line computer- 
based environment* 

20 It will be understood that the improved remote gaming 

mechanism, together with associated communication units, 
protocols and message formats supporting the gaming 
mechanism, as described above, provides at least the 
following advantages: 

25 (i) Remote gaming is provided directly between two 

terminals, without the need for a gaming server. This is 
priitiarily achieved due to the provision of fewer messages 
together with the results of contests being determined by 
each terminal - 

30 (ii) As each game message contains all gaming 

data, it is not necessary for the terminals to retain 
gaming data. 
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(iii) The use of standard attributes, such as 
character,, weapons, armour etc, means that only 
references need be transmitted between terminals, rather 
than full graphical representations and characteristics 
5 for those attributes, significantly reducing the amount 
of data required to be transmitted. 

Whilst the specific and preferred implementations of the 
embodiments of the present invention are described above, 
10 it is clear that one skilled in the art could readily 
apply variations and modifications of such inventive 
concepts* 

Thus, an improved remote gaming mechanism, together with 
15 associated communication units, protocols and message 
formats supporting the gaming mechanism, has been 
described where the aforementioned disadvantages with 
prior art arrangements have been substantially 
alleviated * 
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Claims 

1. A communication unit (110, 120) for playing a game 
with a second remote communication unit, the 

5 communication unit comprising: 

a receiver, for receiving a gaming message (210) 

from the second communication unit where the message 

includes challenge data to initiate a contest with the 

second remote communication unit; 
10 a processor (160), operably coupled to the 

receiver, containing software for extracting said 

challenge data from the gaming message; 

the communication unit characterised in that: 

the processor processes response data relating to 
15 the challenge, either input by a user of the 

communication unit or stored in a memory element of the 

communication unit, and determines an outcome of the 

contest based on said received challenge data and said 

response data. 

20 

2, The communication unit (110, 120) according to 
Claim 1, wherein said processor (160) generates a 
response message from said response data, the 
communication unit further characterised by: 

25 a transmitter, for transmitting a response message 

to the second communication unit, wherein the response 
message includes opponent data for the communication unit 
to participate in said contest. 

30 3- The communication unit (110, 120) according to 

Claim 2, the communication unit further characterised by 
the response message further comprising the extracted 
challenge data. 
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4» The communication unit according to Claim 2 or 

Claim 3, the communication unit further characterised by 
the response message and or challenge message further 
5 comprising details of the challenger and/or opponent. 

5. The communication unit (110^ 120) according to 
Claim 1, wherein the communication unit is a wireless 
communication unit, operating over a wireless 

10 communication network. 

6. The communication unit (110, 120) according to 
Claim 1, wherein the processor (160) is configured to 
enact the game substantially in accordance with the 

16 process described in FIG. 6. 

7. The communication unit (110, 120) according to 
Claim 1, wherein the processor (160) is operably coupled 
to a display to display to a user of the communication 

20 unit a list of options to play a game, wherein said 
options include one or more of the following: 

(i) '^Challenge" - create and send a challenge to 
another player; 

(ii) ^^Messages" - view challenges and/or responses 
25 received; 

(iii) ^'Profile" - view the user profile; 

(iv) ^^Attributes'' - change /improve character 
attributes, for example purchasing equipment, training 
etc; 

30 (v) ''^Replay previous contests" - those contests 

that have been saved; and 
(vi) ^^Quit". 



wo 03/092839 



- 37 - 



PCT/GB03/01785 



8. The communication unit (llO, 120) according to 
Claim 1, wherein the coinmunication unit is one of: a 
cellular phone, a personal data assistant (PDA), a 
portable or mobile radio, a laptop computer or a 

5 wirelessly networked personal computer (PC) that is able 
to support remote gaming. 

9. The communication unit (110/ 120) according to 
Claim Ir wherein the second communication unit is a 

10 gaming server (710) configured to 

(i) Initiate challenges to one or more remote 
communication units (110, 120), or 

(ii) Route challenges between two or more remote 
communication units* 

15 

10. The communication unit (110, 120) according to 
Claim 9, wherein the gaming server (710) is configured to 
initiate challenges to one or more remote communication 
units periodically or intermittently, 

20 

11. A gaming server (710) configured to operate as the 
second communication unit in accordance with Claim 1, 

12. A wireless, computer-based or processor-based game 
25 adapted to operate, in the communication unit of Claim 1. 

13. A communication protocol employed by a 
communication unit according to Claim 1^ wherein the 
communication protocol supports a remote gaming mechanism 

30 between two communication units. 

14. The communication protocol according to Claim 13, 
wherein at least one message of the protocol includes 
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both challenger and opponent data, to effect an outcome 
of the contest in either or both of the communication 
units . 

5 15. The communication protocol according to Claim 13 

or Claim 14, wherein a message of the protocol includes 
at least one attack move and at least one defence move 
relating to challenger or opponent data. 

10 16. A communication system (100) adapted to facilitate 
communication (125, 128) between two communication units 
at least one of which is adapted according to Claim 1 or 
support the communication protocol according to Claim 13. 

16 17. A storage medium storing processor-implementable 

instructions for controlling one or more processors in 
the communication unit of Claim 1. 
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